-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature restrict submissions #1817 #1914
base: develop
Are you sure you want to change the base?
Conversation
@gothub - I tested your changes for this PR today and it was not working for me. I changed a metacat instance to restrict submissions to a test group with only my ORCID as a member. I confirmed that this setting was shown in the MN and CN node descriptions. As expected, when logged into my ORCID I was able to submit and everything looked fine. But when I logged into the Kepler ldap account, which is not in my test group, I had a bunch of issues. Below is a list of things to fix. I tried to add a checkbox next to each actionable item. Improvements needed to the warning message
This message:Should look like:
Bug: Can still edit an existing dataset
Bug: Can click Publish
Bug: Can edit portalsI was able to click "Edit" on an existing portal and submit changes (with a resulting error from Metacat).
Bug: When I signed out, the warning message was displayed
Bug: Sometimes the warning message was not displayed at all
I am going to close this PR for now and you can open it again after these issues are fixed. Thanks |
@laurenwalker thanks for the review, I'll start working on fixing the bugs that you described. |
Relates to #1789
@laurenwalker all the issues you mentioned have been resolved. Regarding the error message displayed if a user is not in the allowed submitters list, I implemented it in the same way as error messages used for portals. That is, an error message is defined in AppModel.js, as is done for:
Regarding the AppModel.js Also included is a mercifully short video demonstrating how these changes affect the UI. allow.submitters-issue-.1817-demo.mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gothub Thank you for making the changes we talked about and fixing most of those issues. Below is a list of manual UI tests I created for this PR. Each check mark is a test that passed and each empty check box is a failed test, with an Error message below it.
Please review and fix all the failed tests below. It would be helpful to have you run through the tests again before submitting another PR review.
Additional comments:
- I wasn't sure if we had decided to support the
denied submitter
list in the UI for this PR. As you can see in the list below, each of the tests for the Denied Submitter list failed because I don't think it's checked in MetacatUI. We may decide to skip that functionality for now if it significantly delays the release of this work so far. - Regarding the
checkAllowedSubmitters
config: I think this can be set totrue
by default so that repo admins don't have to update the Metacat AND MetacatUI config for the feature to work. I originally suggested this as a feature flag because I thought it would prevent the node info doc from being grabbed for nodes that don't need to parse it for the allowed submitter list (which slows down the app load time by having to wait for another XHR to finish). But as I mentioned in my code comment above, I noticed that the node info doc is grabbed regardless. We should only send that extra request if either the member node is not in the CN node list OR if thecheckAllowedSubmitters
is set to true.
When AllowedSubmitters is disabled in MetacatUI and Metacat
- The Edit button displays for datasets
- The Edit button displays for portals in the portal view
- The Edit button displays for portals in the portal list
- The "New" button displays for portals
- The dataset editor renders w/o a message
- The portal editor renders w/o a message
- Can edit an existing package
- Can create a new package
- Can edit an existing portal
- Can create a new portal
- The "not auth" message still displays for datasets I don't have write permissions for
- The "not auth" message still displays for portals I don't have write permissions for
- The provenance editor is displayed
When AllowedSubmitters is set to my ORCID
- The Edit button displays for datasets
- The Edit button displays for portals in the portal view
- The Edit button displays for portals in the portal list
- The "New" button displays for portals
- The dataset editor renders w/o a message
- The portal editor renders w/o a message
- Can edit an existing package
- Can create a new package
- Can edit an existing portal
- Can create a new portal
- The "not auth" message still displays for datasets I don't have write permissions for
- The "not auth" message still displays for portals I don't have write permissions for
- The provenance editor is displayed
When AllowedSubmitters is set to my group
- The Edit button displays for datasets
- The Edit button displays for portals
- The "New" button displays for portals
- The dataset editor renders w/o a message
- The portal editor renders w/o a message
- Can edit an existing package
- Can create a new package
- Can edit an existing portal
- Can create a new portal
- The "not auth" message still displays for datasets I don't have write permissions for
- The "not auth" message still displays for portals I don't have write permissions for
- The provenance editor is displayed
When I am not in the AllowedSubmitter list
- The Edit button does not display for datasets
- The Edit button does not display for portals in the portal list
- The Edit button does not display for portals in the portal view
- The "New" button does not display for portals
- Error: When I go to /portals to view the portal list there is a New Portal button
- The dataset editor doesn't render and shows a message for a new dataset (/submit)
- The dataset editor doesn't render and shows a message for an existing dataset (/submit/id)
- The portal editor doesn't render and shows a message
- When navigating to the view
- When refreshing the page on the view
- For a new portal (/edit/portals)
- Error: The portal editor still renders when creating a new portal (at /edit/portals) and there is no message
- [x] For an existing portal (/edit/portals/{id})
- The provenance editor is not displayed
When I am in the DeniedSubmitter list
All of the below tests failed when my ORCID is in the denied submitter list, but the allowed submitter list is either empty or set to someone else. I think the denied submitter list is not checked at all. Did we decide that was out of scope for now?
- The Edit button does not display for datasets
- Error: I still see the Edit and Publish buttons for datasets when I am in the denied submitter list:
- The Edit button does not display for portals in the portal list
- Error The Edit button still shows up in the portal list
- The Edit button does not display for portals in the portal editor
- Error The Edit button still shows up in the portal editor
- The "New" button does not display for portals
- Error The New button still shows up in the portals list
- The dataset editor doesn't render and shows a message for a new dataset (/submit)
- Error The dataset editor still fully renders and doesn't show a message when I navigate directly to /submit or click Submit Data
- The dataset editor doesn't render and shows a message for an existing dataset (/submit/id)
- Error: The dataset editor still renders for an existing dataset when I am in the denied submitter list, and there is no message
- The portal editor doesn't render and shows a message
- Error All of the below tests failed. The portal editor always renders for my portals and for new portals
- When navigating to the view
- When refreshing the page on the view
- For a new portal (/edit/portals)
- For an existing portal (/edit/portals/{id})
- The provenance editor is not displayed
- Error The prov editor renders for my datasets
DataONE theme testing
The following tests are for the DataONE theme, which supports the portal editor but not the dataset editor or provenance editor.
To test the dataone theme portal features with the dev.nceas member node, use the search-stage
MetacatUI configuration in the metacatui-config
repo.
DataONE theme only: When I am in the AllowedSubmitter list
- The Edit button displays for portals in the portal list
- The Edit button displays in the portal view
- The "New" button displays for portals
- The portal editor renders for new portals (/edit/portals)
- The portal editor renders for an existing portal (/edit/portals/{id})
- The "not auth" message still displays for portals I don't have write permissions for
DataONE theme only: When I am not in the AllowedSubmitter list
- The Edit button does not display for portals in the portal list
- Error: The Edit button displays for my portals
-
The Edit button does not display in the portal view
- Error: The Edit buttons displays int he portal view
-
The "New" button does not display for portals
- Error: The New button displays in the portal list
- The portal editor does not render for new portals (/edit/portals)
- Error: The new portal editor still renders
- The portal editor does not render for an existing portal (/edit/portals/{id})
- Error: The portal editor still renders when I try to edit an existing portal
DataONE theme only: When I am in the DeniedSubmitter list
Again, not sure if this is out-of-scope for now
- The Edit button does not display for portals in the portal list
- Error: The Edit button displays for each of my portals in the list
- The Edit button does not display in the portal view
- Error: The Edit button displays for my portals
- The "New" button does not display for portals
- Error The New button shows up in the portal list
- The portal editor does not render for new portals (/edit/portals)
-
- Error: The portal editor fully renders
-
- The portal editor does not render for an existing portal (/edit/portals/{id})
- Error: The portal editor fully renders
* (see https://releases.dataone.org/online/api-documentation-v2.0/apis/CN_APIs.html#CNCore.listNodes) | ||
* @type {string} | ||
*/ | ||
getCapabilitiesServiceUrl: null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this the same as the AppModel.nodeServiceUrl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see that the nodeServiceUrl is for the CN and getCapabilitiesServiceUrl is for the MN.
} | ||
}); | ||
}, | ||
|
||
getCapabilities: function(){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this method name is misleading because more than the node capabilities are retrieved and set on the model. If we are only setting the node capabilities, then let's keep this name. But if we are setting all of the node properties (which it appears we are based on like 127 (thisModel.saveNodeInfo(xmlResponse);
)), then let's name this method something more appropriate like getMemberNodeInfo()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also please add a method description using JSDoc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'll update the method call name and create the JSDoc entry.
if(!thisModel.get("nodeInfoFound")) { | ||
thisModel.getCapabilities(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice that the app never sets this attribute (nodeInfoFound
) so the member node doc will always be retrieved. When the CN node info doc is parsed, let's check if the current member node was found in the list and if not, set nodeInfoFound
to false.
Even better, we could just use NodeModel.getMember()
to see if the current member node is already set on the model. If getMember()
doesn't return our node, then we know it wasn't found in the CN node list.
This does mean that the member node info doc needs to be synced with the CN for the changes in this PR to work. Right now I'm testing with dev.nceas and it hasn't synced with the CN, so everything has been working in my tests so far because the member node info doc is grabbed directly from dev.nceas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea on using NodeModel.getMember()
, I'll implement the use of that.
The MN config change (updating allowed.submitters
is only changed when the metcat admin config for DataONE is updated (i.e. https://dev.nceas.ucsb.edu/knb/admin?configureType=dataone), even though the allow.submitters
property is changed in the global properties
admin menu, (https://dev.nceas.ucsb.edu/knb/admin?configureType=properties). Maybe this needs a revisit on design?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, denied.submitters
should be implemented, but could that happen in a later release (ESS-DIVE hasn't requested this)?
This PR makes these changes: